Skip to content

Treat 2026-07-28 as a released spec revision; keep draft for what comes after it - #495

Draft
pcarleton wants to merge 11 commits into
mainfrom
pcarleton/2026-07-28-released
Draft

Treat 2026-07-28 as a released spec revision; keep draft for what comes after it#495
pcarleton wants to merge 11 commits into
mainfrom
pcarleton/2026-07-28-released

Conversation

@pcarleton

@pcarleton pcarleton commented Sep 6, 2026 •
edited by claude Bot
Loading

Copy link
Copy Markdown
Member

Requested by Paul Carleton · Slack thread

Fixes #426.

Why

The 2026-07-28 specification revision was released on 2026-07-28, but the harness still modelled it as "the draft": LATEST_SPEC_VERSION was 2025-11-25, DRAFT_PROTOCOL_VERSION = '2026-07-28' served as both the draft's wire string and its identity on the spec timeline, every SEP-2575/2322/2243/2549/2468 scenario was tagged introducedIn: DRAFT_PROTOCOL_VERSION, and tier-check filed all of them under "Informational (not scored)". #447 already froze requirements/2026-07-28.yaml, so the --requirements path treated the revision as shipped while everything else did not.

We still want draft to be something the suite can represent (the revision after the latest release), but it has to stop being shorthand for "the 2026-07-28 stateless era". The spec repo's schema/draft/schema.ts currently declares the same LATEST_PROTOCOL_VERSION (2026-07-28) as the release, so the draft's identity and its wire string can no longer be one value.

The second goal is that the next release should not need a PR this size. See "Next time" below.

What changes

Model (src/types.ts)

  • DATED_SPEC_VERSIONS gains 2026-07-28; LATEST_SPEC_VERSION is derived as its last entry. 2025-11-25 stays fully supported.
  • DRAFT_SPEC_VERSION = 'draft' is the timeline identity of the unreleased revision after the latest release. SpecVersion = DatedSpecVersion | 'draft'.
  • DRAFT_PROTOCOL_VERSION is the draft's wire protocolVersion, now read from the vendored schema/draft/schema.ts (still 2026-07-28 today). protocolVersionFor(v) maps a SpecVersion to its wire string and is used everywhere a version goes on the wire: headers, _meta, mock supportedVersions, MCP_CONFORMANCE_PROTOCOL_VERSION.
  • Era behaviour comes from predicates (isStatefulVersion / isStateless, specVersionAtLeast(v, '2026-07-28')) instead of === DRAFT_PROTOCOL_VERSION, so the next revision inherits it.

Scenarios

  • All 34 introducedIn: DRAFT_PROTOCOL_VERSION tags become '2026-07-28' (the one further tag that arrived from main, the DPoP authorization-server scenario for SEP-1932, becomes DRAFT_SPEC_VERSION instead because DPoP is not in the 2026-07-28 release); all 15 removedIn: DRAFT_PROTOCOL_VERSION tags (initialize, sessions, ping, logging/setLevel, resources/subscribe, SSE resumption, elicitation defaults/enums, the sampling/elicitation/logging tool calls) become removedIn: '2026-07-28'. Verified against the 2026-07-28 changelog.
  • Those scenarios join the default suites: server active goes from 31 to 48 scenarios; the eleven 2026-07-28 auth scenarios (SEP-2468 iss, SEP-2207 offline access, SEP-2352 migration, resource-mismatch) join auth/core. --suite draft (client and server) is kept and is currently empty; it prints a one-line note saying so.
  • Scenario imports of spec-types/draft move to the newly vendored spec-types/2026-07-28.

Defaults when --spec-version is omitted

  • Each scenario runs at the latest release if it applies there, otherwise at the newest revision inside its window: draft-only at the draft, removedIn: '2026-07-28' at 2025-11-25, the 2025-03-26 backcompat pair at 2025-03-26. Previously everything that was not draft-only ran at 2025-11-25. A server or client that only implements the stateful lifecycle should pass --spec-version 2025-11-25.

CLI back-compat

  • --spec-version draft still parses. It means "the revision after 2026-07-28": the same scenario set as --spec-version 2026-07-28 plus any draft-only scenarios (one today: the authorization-server dpop scenario), run at the draft's wire version (also 2026-07-28 today). It prints one stderr line noting that 2026-07-28 is a released revision.
  • --suite draft still parses; empty today, with a one-line note.
  • --spec-version 2026-07-28 and --requirements 2026-07-28 keep their meaning; the former now selects 37 server scenarios instead of 20 because the 17 formerly-draft scenarios are no longer excluded from active.

tier-check (#426)

  • 2026-07-28 scenarios score. Only draft and extension are informational, and a scored scenario that also applies at the draft is not listed a second time under the informational columns.
  • URL mode with neither --requirements nor --spec-version now scores against the latest shipped revision's frozen requirement set (requirements/2026-07-28.yaml) and says so on stderr (only when --conformance-server-url or --client-cmd is given, so a GitHub-only run claims no revision), instead of an unfiltered --suite all client leg that counted the removed 2025-03-26 backcompat scenarios and ran them on the wrong wire. --requirements 2025-11-25,2026-07-28 claims both; --spec-version keeps the unfrozen per-version path. --sdk mode is unchanged (every shipped revision).

Vendored schema

  • scripts/sync-schema.ts now vendors every DATED_SPEC_VERSIONS entry plus draft and generates src/spec-types/schemas.ts (the version to JSON Schema map the wire validator imports). Everything is re-synced at the 2026-07-28 tag (5f5440bb), so 2026-07-28 validates against its own immutable schema. The re-vendored 2025-06-18/2025-11-25 schemas carry the upstream NumberSchema fix (modelcontextprotocol#3139), so the local erratum and its tripwire test are removed.

sdk-runner

  • specOverrides keys are dated versions; a draft run resolves its overlay through the draft's wire version, falling back to the latest release's entry when the draft's wire version has none.

Docs and tests

  • README, --help, the tier-audit skill and AGENTS.md (one new bullet on how to tag introducedIn) describe 2026-07-28 as released and draft as the revision after it; src/spec-types/README.md gains the spec lifecycle checklist. Tests pin '2026-07-28' / '2025-11-25' explicitly where they meant "stateless" / "stateful"; the unit-test context helpers default to 2025-11-25 because that is what the bundled SDK client/server speak.

Next time

After this PR the per-release edit set is:

  1. Append the date to DATED_SPEC_VERSIONS (LATEST_SPEC_VERSION follows).
  2. npm run sync-schema -- <release tag> (vendors the new schema/<date>, regenerates schemas.ts; DRAFT_PROTOCOL_VERSION tracks the vendored draft on its own).
  3. Retag the scenarios that shipped: DRAFT_SPEC_VERSION to the date in introducedIn / removedIn.
  4. Freeze requirements/<date>.yaml.
  5. specOverrides entries for SDKs that need a different server invocation at the new wire.

A draft marker bump upstream (e.g. DRAFT-2026-v2) is step 2 alone. Help text, the draft notes, the stateless version lists, tier-check columns and the wire validator all derive from DATED_SPEC_VERSIONS.

Cross-SDK check (local sdk matrix, all KNOWN_SDKS, this branch vs main)

These numbers were measured at 6b8c76f, before main was merged in at 0570f2a; the checks main added will have moved the per-check totals.

  • --requirements 2026-07-28 and --requirements 2025-11-25, server and client legs: per-SDK, per-scenario results are identical before and after for typescript-sdk, typescript-sdk-v1, python-sdk, python-sdk-v1, go-sdk, csharp-sdk, ruby-sdk (rust-sdk did not build in the environment used, unrelated to this change). The tier path does not move.
  • --mode server with no flags: typescript-sdk, python-sdk, ruby-sdk go from 73/73 to 151/151 checks (the 17 stateless scenarios now run); go-sdk and csharp-sdk fail those 17 plus the spanning scenarios because their default KNOWN_SDKS server invocation is the stateful-era one and specOverrides['2026-07-28'] only applies when a version is requested. --spec-version 2026-07-28 (or draft) and --requirements pick the right invocation and are green; see the open question below.
  • --mode client --suite core with no flags: every Tier 1 client (typescript, go, python, csharp, ruby) passes the enlarged suite at 2026-07-28; the v1 lines stay pinned to 2025-11-25 and are unchanged.
  • --mode server --spec-version draft: typescript 119/119, go 120/120, python 119/119, ruby 119/119, csharp 2 warnings, matching --spec-version 2026-07-28.

Full tables are in the first comment.

SDK impact

  • CI that runs server / client with no --spec-version now exercises 2026-07-28 scenarios at the stateless wire by default (spanning scenarios included). SDKs that only implement 2025-11-25, or whose conformance server speaks one era per process, should pin --spec-version (or use --requirements, which most already do). Expected-failures baselines keyed to the old default will see new scenario names.
  • CI that passes --spec-version draft keeps working and now scores; switch to --spec-version 2026-07-28 at leisure.
  • CI that passes --suite draft now runs zero scenarios (with a note); switch to the default suite or --spec-version 2026-07-28.
  • --requirements users and tier-check --sdk: no change.

Open questions

  • Should sdk <name> with no version resolve specOverrides[LATEST_SPEC_VERSION] so go-sdk/csharp-sdk start their stateless server by default? That would flip which half of the mixed default suite fails for them; the real fix is that a no-flag run against a one-era-per-process server is not meaningful, and --requirements already handles it per revision. Left as is here.
  • The in-repo example client's OAuth handlers are stateful-only, so client --suite auth against it without --spec-version 2025-11-25 reports failures for auth/scope-step-up and auth/scope-retry-limit. The scenarios themselves pass against every SDK client.

Not in this PR

  • specReferences / src/seps/*.yaml URLs still point at /specification/draft/.... Those pages were restructured before the release (authorization split, transports to transports/streamable-http, utilities/mrtr to patterns/mrtr, ...), so moving them to /specification/2026-07-28/... is a page-and-anchor remap plus a traceability.json regen, not a rename. Follow-up.

AI disclosure

Per the org AI contribution policy: this PR was written primarily by Claude Code (audit of the draft usages, code changes, tests, the cross-SDK matrix runs and this description), working from my direction on the design (keep draft as the revision after the latest release, promote 2026-07-28, make the next release a small diff). I have reviewed the changes and the before/after numbers come from real local runs.

@pcarleton
Vendor spec schemas at the 2026-07-28 release tag
28017c3 
Adds schema/2026-07-28 to the sync script and re-vendors every version at
5f5440bb (the 2026-07-28 tag). draft and 2026-07-28
are identical there apart from doc links; the dated 2025-06-18/2025-11-25
schemas pick up the upstream NumberSchema generator fix (#3139).
@pcarleton
Make 2026-07-28 the latest dated spec version; keep draft as the revi…
ef218ed 
…sion after it

2026-07-28 shipped, but the harness still modelled it as the draft:
LATEST_SPEC_VERSION was 2025-11-25 and DRAFT_PROTOCOL_VERSION doubled as
both the draft's wire string and its timeline identity. Now that the spec
repo's draft declares the same wire version as the release, those two roles
have to be separate things.

- DATED_SPEC_VERSIONS gains 2026-07-28 and LATEST_SPEC_VERSION points at it.
- DRAFT_SPEC_VERSION ('draft') is the timeline id after the latest release;
  DRAFT_PROTOCOL_VERSION stays the draft's wire string (still 2026-07-28,
  mirroring schema/draft/schema.ts). protocolVersionFor() maps a SpecVersion
  to its wire string and is used wherever a version goes on the wire
  (headers, _meta, supportedVersions, MCP_CONFORMANCE_PROTOCOL_VERSION).
- Without --spec-version each scenario now runs at the latest release if it
  applies there, else the newest revision in its window (defaultSpecVersionFor),
  so stateful-only scenarios keep the initialize wire and nothing is handed a
  lifecycle it cannot speak.
- --spec-version draft and --suite draft still parse; each prints a one-line
  note (2026-07-28 is released / the draft suite is currently empty).
- Wire-schema validation routes 2026-07-28 to its own vendored schema and
  drops the NumberSchema erratum the re-vendored dated schemas no longer need.
- sdk-runner: specOverrides keys are dated versions; a draft run resolves its
  overlay through the draft's wire version.
- Test helpers default to 2025-11-25 (what the bundled SDK client/server
  speak) now that the latest release is stateless.
@pcarleton
Retag scenarios that shipped in 2026-07-28 and derive era behaviour f…
6c6329c 
…rom predicates

Every scenario tagged introducedIn/removedIn: DRAFT_PROTOCOL_VERSION covers a
requirement that shipped (or was removed) in 2026-07-28, so tag them with the
date. They join the default suites (active, auth, core) and tier scoring; the
draft suites are left for genuinely unreleased requirements and are empty.

In-scenario 'is this the draft?' checks become era/feature predicates so the
next revision inherits them: isStateless(ctx) for lifecycle, specVersionAtLeast
(v, '2026-07-28') for SEP-2106/2350/837 gating, and protocolVersionFor() for
hand-built headers, _meta and mock supportedVersions. Scenario imports of
spec-types/draft move to spec-types/2026-07-28. withRequiredDraftResultFields
is renamed withRequiredResultFields; the vestigial specVersions field on the
input-required-result scenarios is dropped. The example client keys its
lifecycle off the wire version list and defaults to the latest release.
@pcarleton
tier-check: score 2026-07-28 as a release and default to the latest r…
c719ec4 
…equirement set

Fixes #426. With 2026-07-28 dated, its scenarios count toward the tier
matrix; only genuinely-draft and extension scenarios stay informational,
and a scored scenario that also applies at the draft no longer shows up a
second time in the informational columns.

In URL mode with neither --requirements nor --spec-version, tier-check used
to run the client leg as an unfiltered --suite all, which put the removed
2025-03-26 backcompat scenarios in the denominator and ran them on the wrong
wire. It now scores against the latest shipped revision's frozen requirement
set (requirements/2026-07-28.yaml) and says so on stderr; --requirements
claims more revisions, --spec-version keeps the unfrozen per-version path.
@pcarleton
Docs: 2026-07-28 is a released revision; draft is the one after it
39768ce 
README/--help/skill wording that described 2026-07-28 as 'the draft' now
names it as a dated release, explains what --spec-version draft and
--suite draft mean after a release, and documents the new no-flag defaults
(per-scenario wire selection; tier-check scoring the latest requirement
set). AGENTS.md gains a line on how to tag introducedIn for shipped vs
draft-only requirements.
@pcarleton
Update tests for the released-2026-07-28 model
38a9d48 
Tests that used DRAFT_PROTOCOL_VERSION to mean 'the stateless revision' pin
'2026-07-28' explicitly, tests that relied on LATEST_SPEC_VERSION being
stateful pin '2025-11-25', and the draft-suite/alias expectations follow the
new DRAFT_SPEC_VERSION identity. New coverage: defaultSpecVersionFor,
protocolVersionFor at the header/_meta/env boundaries under --spec-version
draft, the draft→wire specOverrides lookup, and LATEST_SPEC_VERSION having
a frozen requirement set. all-scenarios runs each fixture scenario at its
default revision and again on 2025-11-25 when it spans both wires.
draft-result-fields.test.ts is renamed required-result-fields.test.ts.
@pcarleton
Make the next spec release a two-line change to the version plumbing
6b8c76f 
Promoting 2026-07-28 touched the schema list in three places and every help
string that named a date. Derive them instead, so the next release is
'append the date to DATED_SPEC_VERSIONS, run sync-schema' plus the
inherently per-release work (retag shipped scenarios, freeze a requirement
set):

- LATEST_SPEC_VERSION is the last DATED_SPEC_VERSIONS entry, not a second
  constant.
- DRAFT_PROTOCOL_VERSION is read from the vendored schema/draft/schema.ts, so
  a draft marker bump upstream is just `npm run sync-schema`.
- sync-schema vendors DATED_SPEC_VERSIONS + draft (no separate list) and
  generates src/spec-types/schemas.ts, the version -> JSON Schema map the wire
  validator imports; wire-schema.ts no longer hardcodes imports per version.
- --spec-version/--requirements help and error text interpolate the version
  list instead of naming dates.
- Tests that pinned exact list contents assert structure instead.
- src/spec-types/README.md gains the spec lifecycle checklist (draft marker
  bump / new draft-only scenario / new release).
@pcarleton

pcarleton commented Sep 6, 2026 •
edited by claude Bot
Loading

Copy link
Copy Markdown
Member Author

Cross-SDK matrix for this branch (6b8c76f) vs main (98535fb), run locally with the sdk runner over every KNOWN_SDKS entry (rust-sdk did not build in the environment used, a dependency resolution issue unrelated to this change). "before" = main, "after" = this branch. Status cells are passed/(passed+failed) checks.

Leg SDK before (main) after (this branch)
server, no flags (default suite) typescript-sdk ✅ 73/73 checks ✅ 151/151 checks
server, no flags (default suite) go-sdk ✅ 73/73 checks ❌ 48 failed, 6 warnings / 135 checks
server, no flags (default suite) python-sdk ✅ 73/73 checks ✅ 151/151 checks
server, no flags (default suite) csharp-sdk ✅ 73/73 checks ❌ 48 failed, 5 warnings / 134 checks
server, no flags (default suite) ruby-sdk ✅ 73/73 checks ✅ 151/151 checks
server --requirements 2025-11-25 csharp-sdk ✅ 80/80 checks ✅ 81/81 checks
client --suite core, no --spec-version typescript-sdk ✅ 250/250 checks ✅ 356/356 checks
client --suite core, no --spec-version go-sdk ✅ 263/263 checks ✅ 394/394 checks
client --suite core, no --spec-version python-sdk ✅ 238/238 checks ✅ 358/358 checks
client --suite core, no --spec-version rust-sdk ❌ 50 failed, 0 warnings / 50 checks ❌ 62 failed, 0 warnings / 64 checks
client --suite core, no --spec-version csharp-sdk ✅ 229/229 checks ✅ 328/328 checks
client --suite core, no --spec-version ruby-sdk ✅ 236/236 checks ✅ 362/362 checks
client --suite extensions typescript-sdk ❌ 1 failed, 0 warnings / 49 checks ❌ 1 failed, 0 warnings / 45 checks
client --suite extensions python-sdk ❌ 9 failed, 0 warnings / 60 checks ❌ 9 failed, 0 warnings / 59 checks
client --suite extensions csharp-sdk ❌ 9 failed, 1 warnings / 51 checks ❌ 9 failed, 1 warnings / 45 checks
client --suite extensions ruby-sdk ❌ 9 failed, 0 warnings / 57 checks ❌ 9 failed, 0 warnings / 56 checks

Not shown above (40 of 56 before/after pairs have an identical Status cell):

  • server, no flags (default suite): identical for typescript-sdk-v1, python-sdk-v1, rust-sdk
  • server --requirements 2026-07-28: all 8 SDKs identical
  • server --requirements 2025-11-25: identical for typescript-sdk, typescript-sdk-v1, go-sdk, python-sdk, python-sdk-v1, rust-sdk, ruby-sdk
  • client --requirements 2026-07-28: all 8 SDKs identical
  • client --requirements 2025-11-25: all 8 SDKs identical
  • client --suite core, no --spec-version: identical for typescript-sdk-v1, python-sdk-v1
  • client --suite extensions: identical for typescript-sdk-v1, go-sdk, python-sdk-v1, rust-sdk
  • server --spec-version draft (after only): after-only leg, so there is no before to diff; it is in the full tables below.
  • The SDK head and Toolchain columns are omitted from the diff because they are the same before and after for every SDK in every leg.

Notes:

  • Every --requirements leg is identical per SDK and per scenario before/after (the failures shown there are baselined or not-scored entries and are the same on main).
  • server with no flags: go-sdk and csharp-sdk fail the 17 newly-active 2026-07-28 scenarios plus the spanning ones because their default KNOWN_SDKS server invocation is the stateful-era process; with --spec-version 2026-07-28, --spec-version draft or --requirements the stateless invocation is selected and they are green. Their own CI pins --spec-version per leg.
  • client --suite core with no flags: every client passes the 11 added auth scenarios and the spanning scenarios at the 2026-07-28 wire; check counts differ because the stateless wire has no initialize checks.
Full tables (all 15, unchanged)

server, no flags (default suite)

before (main)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ✅ 73/73 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ❌ 1 failed, 0 warnings / 73 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ✅ 73/73 checks go 1.27.1
python-sdk 08a3bc8e ✅ 73/73 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ✅ 73/73 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ server failed to start: Server exited with code 127 before tests completed cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ✅ 73/73 checks dotnet 10.0.400
ruby-sdk 8a24e50 ✅ 73/73 checks ruby 3.2.3, bundler 2.4.20

after (this branch)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ✅ 151/151 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ❌ 1 failed, 0 warnings / 73 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ❌ 48 failed, 6 warnings / 135 checks go 1.27.1
python-sdk 08a3bc8e ✅ 151/151 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ✅ 73/73 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ server failed to start: Server exited with code 127 before tests completed cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ❌ 48 failed, 5 warnings / 134 checks dotnet 10.0.400
ruby-sdk 8a24e50 ✅ 151/151 checks ruby 3.2.3, bundler 2.4.20

server --requirements 2026-07-28

before (main)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ❌ 30 failed, 0 warnings / 193 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ❌ 145 failed, 5 warnings / 156 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ❌ 30 failed, 0 warnings / 194 checks go 1.27.1
python-sdk 08a3bc8e ❌ 25 failed, 0 warnings / 193 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ❌ 101 failed, 5 warnings / 156 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ server failed to start: Server exited with code 127 before tests completed cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ❌ 11 failed, 2 warnings / 192 checks dotnet 10.0.400
ruby-sdk 8a24e50 ❌ 38 failed, 0 warnings / 189 checks ruby 3.2.3, bundler 2.4.20

after (this branch)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ❌ 30 failed, 0 warnings / 193 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ❌ 145 failed, 5 warnings / 156 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ❌ 30 failed, 0 warnings / 194 checks go 1.27.1
python-sdk 08a3bc8e ❌ 25 failed, 0 warnings / 193 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ❌ 101 failed, 5 warnings / 156 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ server failed to start: Server exited with code 127 before tests completed cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ❌ 11 failed, 2 warnings / 192 checks dotnet 10.0.400
ruby-sdk 8a24e50 ❌ 38 failed, 0 warnings / 189 checks ruby 3.2.3, bundler 2.4.20

server --requirements 2025-11-25

before (main)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ✅ 84/84 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ❌ 3 failed, 0 warnings / 81 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ⚠️ 1 warnings / 82 checks go 1.27.1
python-sdk 08a3bc8e ✅ 84/84 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ❌ 1 failed, 0 warnings / 78 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ server failed to start: Server exited with code 127 before tests completed cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ✅ 80/80 checks dotnet 10.0.400
ruby-sdk 8a24e50 ⚠️ 2 warnings / 78 checks ruby 3.2.3, bundler 2.4.20

after (this branch)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ✅ 84/84 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ❌ 3 failed, 0 warnings / 81 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ⚠️ 1 warnings / 82 checks go 1.27.1
python-sdk 08a3bc8e ✅ 84/84 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ❌ 1 failed, 0 warnings / 78 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ server failed to start: Server exited with code 127 before tests completed cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ✅ 81/81 checks dotnet 10.0.400
ruby-sdk 8a24e50 ⚠️ 2 warnings / 78 checks ruby 3.2.3, bundler 2.4.20

client --requirements 2026-07-28

before (main)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ❌ 1 failed, 0 warnings / 453 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ❌ 60 failed, 0 warnings / 268 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ❌ 13 failed, 0 warnings / 457 checks go 1.27.1
python-sdk 08a3bc8e ❌ 9 failed, 0 warnings / 469 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ❌ 64 failed, 0 warnings / 368 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ 92 failed, 0 warnings / 104 checks cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ❌ 11 failed, 1 warnings / 417 checks dotnet 10.0.400
ruby-sdk 8a24e50 ❌ 9 failed, 0 warnings / 467 checks ruby 3.2.3, bundler 2.4.20

after (this branch)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ❌ 1 failed, 0 warnings / 453 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ❌ 60 failed, 0 warnings / 268 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ❌ 13 failed, 0 warnings / 457 checks go 1.27.1
python-sdk 08a3bc8e ❌ 9 failed, 0 warnings / 469 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ❌ 64 failed, 0 warnings / 368 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ 92 failed, 0 warnings / 104 checks cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ❌ 11 failed, 1 warnings / 417 checks dotnet 10.0.400
ruby-sdk 8a24e50 ❌ 9 failed, 0 warnings / 467 checks ruby 3.2.3, bundler 2.4.20

client --requirements 2025-11-25

before (main)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ❌ 1 failed, 0 warnings / 308 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ❌ 13 failed, 0 warnings / 297 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ❌ 13 failed, 0 warnings / 285 checks go 1.27.1
python-sdk 08a3bc8e ❌ 9 failed, 0 warnings / 307 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ❌ 14 failed, 0 warnings / 301 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ 65 failed, 0 warnings / 65 checks cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ❌ 11 failed, 1 warnings / 283 checks dotnet 10.0.400
ruby-sdk 8a24e50 ❌ 9 failed, 0 warnings / 302 checks ruby 3.2.3, bundler 2.4.20

after (this branch)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ❌ 1 failed, 0 warnings / 308 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ❌ 13 failed, 0 warnings / 297 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ❌ 13 failed, 0 warnings / 285 checks go 1.27.1
python-sdk 08a3bc8e ❌ 9 failed, 0 warnings / 307 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ❌ 14 failed, 0 warnings / 301 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ 65 failed, 0 warnings / 65 checks cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ❌ 11 failed, 1 warnings / 283 checks dotnet 10.0.400
ruby-sdk 8a24e50 ❌ 9 failed, 0 warnings / 302 checks ruby 3.2.3, bundler 2.4.20

client --suite core, no --spec-version

before (main)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ✅ 250/250 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ✅ 270/270 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ✅ 263/263 checks go 1.27.1
python-sdk 08a3bc8e ✅ 238/238 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ❌ 1 failed, 0 warnings / 238 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ 50 failed, 0 warnings / 50 checks cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ✅ 229/229 checks dotnet 10.0.400
ruby-sdk 8a24e50 ✅ 236/236 checks ruby 3.2.3, bundler 2.4.20

after (this branch)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ✅ 356/356 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ✅ 270/270 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ✅ 394/394 checks go 1.27.1
python-sdk 08a3bc8e ✅ 358/358 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ❌ 1 failed, 0 warnings / 238 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ 62 failed, 0 warnings / 64 checks cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ✅ 328/328 checks dotnet 10.0.400
ruby-sdk 8a24e50 ✅ 362/362 checks ruby 3.2.3, bundler 2.4.20

client --suite extensions

before (main)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ❌ 1 failed, 0 warnings / 49 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ✅ 0/0 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ❌ 13 failed, 0 warnings / 13 checks go 1.27.1
python-sdk 08a3bc8e ❌ 9 failed, 0 warnings / 60 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ✅ 0/0 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ 13 failed, 0 warnings / 13 checks cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ❌ 9 failed, 1 warnings / 51 checks dotnet 10.0.400
ruby-sdk 8a24e50 ❌ 9 failed, 0 warnings / 57 checks ruby 3.2.3, bundler 2.4.20

after (this branch)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ❌ 1 failed, 0 warnings / 45 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ✅ 0/0 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ❌ 13 failed, 0 warnings / 13 checks go 1.27.1
python-sdk 08a3bc8e ❌ 9 failed, 0 warnings / 59 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ✅ 0/0 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ 13 failed, 0 warnings / 13 checks cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ❌ 9 failed, 1 warnings / 45 checks dotnet 10.0.400
ruby-sdk 8a24e50 ❌ 9 failed, 0 warnings / 56 checks ruby 3.2.3, bundler 2.4.20

server --spec-version draft (after only)

SDK SDK head Status Toolchain
typescript-sdk 5119ee7f ✅ 119/119 checks node 22.23.2, pnpm 10.26.1, npm 10.9.8
typescript-sdk-v1 12b42567 ❌ 95 failed, 5 warnings / 106 checks node 22.23.2, pnpm 12.3.4, npm 10.9.8
go-sdk a5026ea ✅ 120/120 checks go 1.27.1
python-sdk 08a3bc8e ✅ 119/119 checks uv 0.12.10, python 3.12.3
python-sdk-v1 8c2fa6ea ❌ 62 failed, 5 warnings / 106 checks uv 0.12.10, python 3.12.3
rust-sdk 3023198 ❌ server failed to start: Server exited with code 127 before tests completed cargo 1.96.1, rustc 1.96.1
csharp-sdk df11d7da ⚠️ 2 warnings / 116 checks dotnet 10.0.400
ruby-sdk 8a24e50 ✅ 119/119 checks ruby 3.2.3, bundler 2.4.20

Collapsed to a before/after diff by Claude Code at the author's request; the original tables are unchanged in the block above.

@JosephDoUrden JosephDoUrden mentioned this pull request Sep 7, 2026
Open
@claude claude Bot mentioned this pull request Sep 24, 2026
Draft
@claude
Merge main into pcarleton/2026-07-28-released
0570f2a 
Bring the branch up to date with main (tools-name-format on 2025-11-25+,
deterministic tools/list ordering, the DNS-rebinding initialized
notification, RFC 8707 resource parameter, custom-header schema freshness,
skills server conformance, DPoP authorization-server scenario, 0.2.0-alpha.12).

Conflicts:
- src/scenarios/server/dns-rebinding.ts: keep main's initialized
  notification after an accepted probe (and the session id it forwards), on
  this branch's version model: the probe still takes (stateless,
  protocolVersion) from isStateless(ctx) / protocolVersionFor(), and the
  notification is skipped for the stateless lifecycle via !stateless rather
  than by comparing against DRAFT_PROTOCOL_VERSION.
- src/scenarios/server/tools.ts: keep main's specVersionAtLeast / SpecVersion
  imports for the name-format and ordering checks; drop the
  DRAFT_PROTOCOL_VERSION import, since this branch already retagged the three
  removedIn tags to '2026-07-28'.

Main-only code that still assumes DRAFT_PROTOCOL_VERSION is a spec tag is
adapted in the next commit.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qo1j9qYJ4u9QvPuwqsaWod
@claude
Adapt main's DPoP and skills code to the released-2026-07-28 model
a12810b 
After the merge, code that landed on main since this branch was cut still
treated DRAFT_PROTOCOL_VERSION as a spec-timeline tag and imported the
renamed withRequiredDraftResultFields, so the tree did not typecheck.

- authorization-server/dpop.ts: introducedIn DRAFT_SPEC_VERSION. SEP-1932
  did not ship in the 2026-07-28 release: neither the 2026-07-28 changelog
  nor the vendored 2026-07-28 schema mentions DPoP, the profile is a draft
  on a modelcontextprotocol/ext-auth branch, and requirements/2026-07-28.yaml
  lists the client DPoP scenarios as not scored (extension). Keeping it at
  the draft preserves main's intent that it is not part of a dated revision.
- client/skills mock: withRequiredResultFields, and the initialize fallback
  comes from protocolVersionFor(<run's spec version>) like the other
  BaseHttpScenario mocks, instead of the draft's wire string. The skills
  scenarios stay extension-tagged, so no timeline tag changes.
- server/skills/enumeration.ts: gate the cache-attribute checks with
  specVersionAtLeast(v, '2026-07-28') rather than a string comparison, which
  only ordered 'draft' after the dates by accident.
- Tests added on main pin '2026-07-28' / '2025-11-25' where they meant
  stateless / stateful, matching how this branch converted their neighbours
  (main's LATEST_SPEC_VERSION meant 2025-11-25 in the DNS-rebinding
  lifecycle test).

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qo1j9qYJ4u9QvPuwqsaWod
@claude
tier-check: only default to the latest requirement set when a leg runs
192f1b1 
URL mode with neither --requirements nor --spec-version now scores against
the latest shipped revision's frozen requirement set. That default also
fired when there was no conformance leg at all (no --conformance-server-url
and no --client-cmd), so a GitHub-only run reported
requirements_revisions: ['2026-07-28'] and "Scored against 2026-07-28"
although both legs were skipped and nothing was measured.

Apply the default only when a server URL or client command is present. An
explicit --requirements is unchanged.

The new test drives the command with the GitHub checks and conformance legs
stubbed and asserts on the printed scorecard.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qo1j9qYJ4u9QvPuwqsaWod
@claude
sdk-runner: fall back to the latest release's overlay for a draft run
5b047ab 
A `draft` run resolves its specOverrides entry through the draft's wire
version, and specOverrides keys must be dated versions. That only works
while the vendored draft schema still declares the latest release's
protocolVersion. As soon as the spec repo gives the draft its own marker
(the "step 2 alone" case), the lookup matches nothing and the run silently
uses the base invocation: go-sdk would start its stateful-era server and
csharp-sdk would be driven at its stateful endpoint for a stateless run.

The draft is the revision after the latest release and inherits its era, so
when the draft's wire version has no entry, use
specOverrides[LATEST_SPEC_VERSION].

The test re-evaluates the modules against a draft schema that declares a
non-dated marker, which is the only way to observe the gap today.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qo1j9qYJ4u9QvPuwqsaWod
@pkg-pr-new

pkg-pr-new Bot commented Nov 11, 2026 •
edited
Loading

Copy link
Copy Markdown

Open in StackBlitz

npx https://pkg.pr.new/@modelcontextprotocol/conformance@495

commit: 5b047ab

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

tier-check: final 2026-07-28 is still treated as draft and legacy scenarios score by default

2 participants

@pcarleton @claude